1. Introduction
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
Most mobile device security systems employ the use of a simple password or PIN to authenticate the user. Despite the ubiquity of password-based systems, it has many problems. An ideal password needs to be easily remembered by the user. However, in order for passwords to be secure, they should be long and hard to predict, contradictory to the former requirement. This is further exacerbated by the proliferation of passwords for the multitude of applications a user typically uses, for which security best practice recommends different passwords should be used.
In addition to application access, some mobile users wish to ensure a high level of security for data (including entire files and data contained within a file or a data structure) on their device, against a number of external threat scenarios. For example, a user may use an app on a tablet or other portable device that synchronizes files with their desktop PC via an online storage service (e.g. Dropbox, Box.com [trademarks]). Some of the downloaded files may contain confidential information such as business documents. The user wishes to safeguard himself against the possibility of a data breach in the event of theft of the device.
A practical way to achieve this today is to enable device encryption on the mobile operating system, which uses an encryption key derived from the device lock screen password. For maximum security, this password should be long and complex. However using a long and complex password as the password to unlock the lock screen is extremely inconvenient for the user. Because of this, most users are reluctant to use any password more complicated than a 4 digit code to unlock the lock screen. A skilled attacker will be able to decrypt any files stored on a stolen device with brute force attack methods. Moreover, the confidential data is decrypted whenever the device has been unlocked, even when the user is not using the data, which increases the risk of a data breach unnecessarily.
Another possible approach to data encryption is for the app to generate its own encryption key. The problem with this approach is that the key would either have to be protected by or derived from a password for security, or has to be stored within the app in plaintext form for usability. The former approach inherits the same password complexity issue as the device encryption method above, while the latter offers little security as the attacker who could compromise the plaintext data could just as easily read the plaintext key and decrypt the data.
In some existing systems an additional level of security has been provided by requiring that an NFC capable mobile phone be first authenticated to the mobile network prior to an application being executed. An NFC token then provides an asymmetric key to the phone which in turn authenticates to a third-party service by performing digital signature within the phone itself.
An example of such a system is shown in US-A-2011/0212707. This, however, displays a number of disadvantages. In particular changing of the application credential requires re-programming or replacement of the token; the number of user credentials secured by the system is limited by the (small) storage capacity of the token; and the loss of the token poses a direct risk of exposure of the user's credentials. In addition, applications running on the mobile device and the server are capable of making use of the described security system only if they have been specifically programmed to do so. The system described cannot be used with pre-existing applications.
Another approach to multi-factor identification is described in US-A-2008/0289030. Here, a contactless token is, upon validation, used to allow access to the authentication credentials secured on the mobile device itself.
This has a number of serious disadvantages, including the necessity of using secure storage on the device. This is normally not available to application developers as it is maintained and controlled by the manufacturer of the device (e.g. mobile phone) or the supplier of the underlying operating system or a mobile network operator. Also, making use solely of a token identifier as a means of validating the token is likely to be insecure. RFID tokens can typically be read by any compatible reader, and can easily be cloned.
Yet a further approach is described in WO-A-2011/089423. This describes a system where the presence of a contactless token is used to authorize execution of a secure function or application, and is aimed primarily at mobile wallet uses.
Again, the system described has a number of disadvantages, primarily that it uses a form of logical control that is relatively easy to circumvent.
More generally, in the enterprise environment there exists significant security risk from allowing users to connect mobile devices into the network due to increased likelihood of unauthorized data access (leading to loss of data confidentiality and/or integrity) resulting from:                Inadvertently disclosed passcodes such as PINS or alphanumeric codes, e.g. from shoulder surfing        Easily guessed passcodes        Lost or stolen devices that are inadequately protected        Unsupervized use of devices by a third party        
The Hoverkey system aims to provide solutions for applications to counter these threats.
With the present invention, the user may store a master key of high cryptographic strength (128 bits or above presently) on the portable security token, and this key can be used to either directly protect an app's data encryption key or a long and complex password, from which a sufficiently long and secure encryption key can be derived. This allows the user to protect any data stored on the device with a very strong encryption key. If the device is stolen, it is then infeasible for any potential attacker to decrypt the encrypted data on it without the associated token.